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The advent of large-scale, complex computing systems has dramatically increased the difficulties of 
securing accesses to systems’ resources. To ensure confidentiality and integrity, the exploitation of 
access control mechanisms has thus become a crucial issue in the design of modern computing sys¬ 
tems. Among the different access control approaches proposed in the last decades, the policy-based 
one permits to capture, by resorting to the concept of attribute, all systems’ security-relevant informa¬ 
tion and to be, at the same time, sufficiently flexible and expressive to represent the other approaches. 
In this paper, we move a step further to understand the effectiveness of policy-based specifications by 
studying how they permit to enforce traditional security properties. To support system designers in 
developing and maintaining policy-based specifications, we formalise also some relevant properties 
regarding the structure of policies. By means of a case study from the banking domain, we present 
real instances of such properties and outline an approach towards their automatised verification. 


1 Introduction 

The ever increasing diffusion of the Internet and the Web has fostered the development of large-scale, 
complex computing systems. These modem distributed systems, that are pervading our everyday life, 
produce and exploit a huge amount of data that are readily available through the underlying network 
platforms. Given their importance and societal impact, it is of paramount importance to ensure that data 
is accessed in a controlled way and that these systems behave in a secure way, e.g. not to compromise 
sensitive data. For achieving this objective, some major challenges come from the fact that the operating 
environment is highly dynamic and open, the involved entities are heterogeneous and possibly untrusted, 
the interactions are complex and unpredictable, and the control is distributed. 

In this setting, we believe that policy-based specifications can be used to regulate the behaviour of 
entities relatively to the access to shared resources, thus ensuring systems security. Policies, that is sets 
of declarative rules expressing what can(not) be done in a system, are indeed high-level abstractions that 
can be used to define various aspects of systems behaviour. In particular, a security policy is a statement 
that defines in which states a system is considered secure. A system is secure if starting from a secure 
state it cannot enter a nonsecure one while computation progresses. The security of a state depends 
on the behaviours the system exposes and, hence, on which guarantees a security policy managing and 
controlling the system ensures. The enforcement of such a policy relies on a combination of various 
approaches, ranging, e.g., from cryptography to access control, according to features and specificity of 
the controlled system. 

We focus on access control, usually considered the first line of defence in protection of computer sys¬ 
tems, networks, and information. Access control is a broad field that covers several different approaches 
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that enable the protection of systems by restricting physical and logical access rights of (authenticated) 
subjects to shared resources. In practice, these approaches establish if a subject’s request to access a 
resource should be permitted or denied according to some given access control rules. 

Since their original introduction in the context of operating systems, to the more recently conceived 
ones for modern distributed applications, many approaches for access control have been proposed in 
the literature. Traditional approaches are based on the identity of the subject, either directly -e.g.. Ac¬ 
cess Control Matrix lIT^ [TSll and its variants Capability Lists and Access Control Lists - or through 
predefined attributes, such as roles or groups assigned to that subject - e.g., Role-Based Access Control 
(RBAC ifTOll ). In our frame of reference, these approaches are cumbersome to manage and not sufficiently 
expressive, given the need to associate access rights to the requester qualifiers of identify, groups, and 
roles fhaf can change frequenlly and could nol be known in advance. To overcome scalabilify problems 
of fhese fradifional access confrol approaches, an alfemafive is fo use Affribufe-Based Access Confrol 
(ABAC 1231). Here, fhe aufhorisafion decision is based on attributes, which represenf arbifrary informa¬ 
tion exposed by fhe sysfem, subjecf, action, objecf, or fhe aufhorisafion confexf ifself fhaf is relevanf fo fhe 
rules af hand. Thus, ABAC permifs defining fine-grained, flexible and confexf-aware access confrol poli¬ 
cies, and foslers sysfems infegrafion, as affribules can be refrieved from differenl information systems. 
Affribufe-based access confrol rules are fypically hierarchically sfrucfured and paired wifh sfrafegies for 
aufomafic frealmenf of conflicting decisions and errors. These sfrucfured specificafions are called poli¬ 
cies', from fhis name derives fhe ferminology Policy-Based Access Confrol (PBAC), somefimes used in 
fhe liferafure in place of ABAC. 

Approaches fo access confrol can be classified also wifh respecf fo ofher feafures. For example, if we 
consider resource ownership fhen we can distinguish befween discretionary access confrol (DAC), where 
subjecfs may decide who can access fheir own resources, i.e. fhe access confrol is af fhe discretion of fhe 
owner, and mandatory access confrol (MAC), where fhe sysfem decides who is allowed fo access any 
resource. In fhis respecf, fhe access confrol mafrix beffer fils fhe DAC approach, while RBAC and ABAC 
can be used bofh for fhe MAC and DAC approaches. To conclude fhis overview of fhe relevanf access 
confrol approaches, on fhe base of fhe resulls in ifT^ . we can say fhaf ABAC is sufficienlly expressive fo 
represenf in an uniform way all fhe ofher approaches. 

Conlrolling accesses fo system resources concerns fhe Ihree main securily principles of confidential¬ 
ity, integrity, and availability. Specifically, confidenlialily refers fo fhe assurance on non-disclosure of 
sensifive resources fo unaulhorised subjecfs; inlegrily fo fhe profeclion of resources from being altered by 
unaulhorised subjecfs; and availabilily fo fhe enablemenl of fhe effective use of resources by aulhorised 
subjecfs. As inslanfiafions of fhese general principles, many securily properties have been inlroduced and 
sludied (e.g., fhe Bell-LaPadula ||3l and Biba [3 models). However, enforcing such properfies by means 
of access confrol policies is a fricky lask. In facl, fhe hierarchical slrucfure of policies, fhe presence of 
conflicl resolution sfrafegies and fhe inlricacies deriving from fhe many involved conlrols do nol permil fo 
easily check whelher a given securily property is properly enforced. Therefore, in our work we consider 
a general inslance of fhe ABAC approach, i.e. fhe FACPL language ll20l . and sludy in delails a sel of 
relevanf securily properfies, presenting how Ihey can be rendered in terms of policy-based specificafions. 

Policy-based specifications are formed by multiple rules and policies, and fo characferise fhe re¬ 
lationships wifh fhe behaviours Ihey enforce, various properties on fhe slrucfure of policies have been 
proposed in fhe liferafure (e.g., change-impacl analysis ifTTI and redundancy minimisafion |[T4l f. The 
approaches used for defining and verifying fhese properfies are differenl and cannol be uniformly repre- 
senfed. Therefore, in our work we focus on a sef of relevanf slrucfural properfies and propose a uniform 
formalisation in lerms of fhe FACPL semantics. 

Furthermore, for providing a concrete support fo fhe verificalion of bofh securily and slrucfural prop- 
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erties, we outline a constraint-based approach enabling automated verification by means of constraint 
solver software tools. At the time of writing, this constraint-based analysis of policies is under develop¬ 
ment; thus, in this paper, we just present main features and strengths of the approach. 

Case Study. We consider a scenario from the banking domain where access control policies are used 
for managing money loan activities. We assume that a costumer willing to borrow money from a bank 
has to fill ouf a loan request document, possibly aided by a bank clerk. Once fhe documenf is finalised, 
fhe clerk submils if for approval; if fhe documenf is approved, fhe loan is granfed. Each loan requesf is 
associafed wifh a confidenlialily level, so fhaf a high confidenfial loan requesf has fo be managed only by 
highly-frusfed clerks. Nofably, fhe approve (resp., submit) acfions of loan requesf documenls are carried 
ouf by clerks fhaf, for safely reasons, cannol do submit (resp., approve) acfions. 

The case sludy is addressed fhroughoul fhe paper. Firsl, we infroduce fhe slrucfure of policies and 
access requesls, Ihen, by characlerising a sel of relevanl securily properties, we define some policies fhaf 
can be used for managing differenl aspecls of fhe money loan acfivilies. 

Outline of the rest of the paper. Section [2] briefly reporls main fealures of policy-based languages and 
inlroduces fhe FACPL policy language. Section |3]presenls fhe represenlalion in terms of policy-based 
specifications and the formalisation of a set of security properties, while Section |4] addresses policies’ 
structural properties. The verification approach, together with our proposal towards an automated tool 
support, is sketched in Section[5] Finally, Section[^reviews more strictly related work and Section|7]con- 
cludes by touching upon directions for future work. Background definitions and concepts on computer 
security used in rest of the paper are based on the well-known text books 

2 A Policy Language 

Policy languages for access control provide high-level abstractions for the specifications of declarative 
sets of access control rules. Specifically, fhese languages allow systems’ designers fo express sfrucfured 
sefs of affribufe-based positive (resp. negative) rules granting (resp. forbidding) fhe access fo systems’ 
resources. In fhis secfion, by informally infroducing (a lighf version of) fhe policy language FACPF |[20l . 
we defail all fhe fypical fealures of access confrol specificalions. The aulhorisalion process fhaf is pursued 
fo aufhorise or forbid an access requesf is ouflined by means of a simple example. 

2.1 Syntax and Informal Semantics of FACPL 

The synfax of a lighf version of FACPF is reporled in Table [T] If is given Irough EBNF-like grammars, 
where as usual fhe symbol ? indicates optional items and -|- indicates non-empfy sequences of items. 

The top-level term is a PDP, which is defined by a sequence of policies Policy^ and an algorifhm 
Alg for combining fhe resulfs of fhe evaluation of fhese policies. 

A policy can be a basic aufhorizalion rule {Effect target iFxpr) or a policy set 
{Alg target :Expr policies -.Policy^} collecting rules and (ofher) policy sefs, so fhaf if is possible fo 
define hierarchical policies. A rule specifies an Effect, i.e. permit or deny, indicating fhe rule-writer’s in- 
fended consequence of a successful evaluafion for fhe rule, and a target, i.e. an expression Expr defining 
fhe applicabilify of fhe rule fo a requesf. A policy instead specifies a fargef, a sequence of confained ele- 
menfs, i.e. rules or policies fhemselves, and an algorifhm Alg for combining fhe resulfs of fhe evaluafion 
of fhese confained elemenfs. 

A combining algorithm implemenfs a sfrafegy for resolving confiicls among fhe decisions resulting 
from fhe evaluation of a collection of rules/policies, e.g. whenever bofh decisions permit and deny are 
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Table 1: Syntax of a light version of FACPL 


Policy Decision Points 

PDF'. 

:= {Alg policies :Poh'cy^} 

Combining algorithms 

Alg: 

:= permit-overrides | deny-overrides | deny-unless-permit 

1 permit-unless-deny | first-applicable | only-one-applicable 

1 weak-consensus | strong-consensus 

Policies 

Policy : 

:= {Effect target :Expr) 

1 {Alg target :Expr policies :PoZ/cy^} 

Effects 

Effect: 

:= permit | deny 

Expressions 

Expr : 

:= Name \ Value \ and{Expr,Expr) \ or{Expr,Expr) \ not{Expr) 

1 equal (Expr,Expr) | \r\ {Expr,Expr) \ greater-than (Expr,Expr) 

1 add (Expr, Expr) | subtract(Expr,Expr) 

1 divide(Expr,Expr) | multiply(Expr,Expr) 

Attribute Names 

Name : 

:= Identifier / Identifier 

Literal Values 

Value : 

:= true | false | Double \ String \ Date 

Access Requests 

Request : 

:= {Name ,Value)^ 


returned. We report below the strategies implemented by some of these algorithms. 

• permit-overrides: if the proeessing of an element returns permit, then the result is permit, 
i.e., permit takes preeedenee over any other deeision. Instead, if at least one element returns 
deny and all others return not-applicable or deny, then the result is deny. If all elements re¬ 
turn not-applicable, then the result is not-applicable. In the remaining eases, the result is 
indeterminate. 

• deny-unless-permit: similarly to permit-overrides, permit takes preeedenee over deny, but it never 
returns not-applicable or indeterminate, which are instead evaluated as deny. 

• strong-consensus: it returns permit (resp., deny) only if all elements return permit (resp., deny). 
If all elements return not-applicable then the result is not-applicable. Otherwise, it returns 
indeterminate. 

A target is an expression indicating the access requests to which a policy applies. Expressions are 
built from attribute names and literal values, i.e. booleans, doubles, strings, and dates, by using standard 
operators. As usual, string values are written as sequences of characters delimited by double quotes. 
For simplicity sake, the expressions syntax does not take types explicitly into account; however, the 
semantics of expressions returns an error if the arguments of operations have incorrect types. The latter 
can be anyway managed by policies by resorting to appropriate combining algorithms. 

An attribute name indicates the value of an attribute within an access request to authorise. Attributes 
are expressed in terms of pairs name-value, where names are structured in the form cat/att, with cat 
standing for a category name (as, e.g., subject, resource, action) and att for a specific name (as, e.g., id 
and role). For example, the structured name subject/role represents the value of the attribute role within 
the category subject. 

An access request represents a subject willing to execute an action that has to be authorised. This 
request holds all the attributes relevant for taking the authorisation decision, such as the information of 
the subject originating the request and that of the requested action. 
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For instance, if we consider the banking case study introduced in Section [T] a request by a subject 
named clerkl with the assigned role assistant, i.e. the clerk assisting a customer, that wants to read the 
resource loanDoc, i.e. the loan request document, is as follows: 

(subject/id,cZerkl) {subiect/ro\e,assistant) {resource/\d,loanDoc) (action/id,re£?d) 

All the other case study actions are dealt with similarly. For example, the submit action of a loanDoc 
by an assistant clerk, or the approve action of a loanDoc by a clerk with the assigned role officier, are 
simply represented by means of a different instantiation of the previous set of attribute names. 

The evaluation of a request with respect to a policy results in one decision among permit, deny, 
not-applicable, and indeterminate. The meaning of the first two decisions is obvious (i.e., granting and 
forbidding the access, respectively), while the third means that there is no policy that applies to the 
request and the fourth means that some errors occur in the evaluation. 

By way of example, to allow read accesses to the resource loanDoc only to subjects with the assigned 
role assistant, we might use the following policy 

{deny-unless-permit 
target: equal(resource/id,ZoanDoc) 

policies : (permit target: equal(action/id,rrarZ) and equal(subject/role,a5mm?it))} 

The evaluation of the previous request with respect to the policy above starts by evaluating the policy’s 
target, i.e. the boolean expression after the first keyword target. Since the request satisfies fhe equal 
comparison funcfion, fhe evaluafion carries on wifh fhe enclosed rule. The rule’s largel is satisfied as 
well and fhe decision permit is returned. Then, the combining algorithm applies to the resulting set of 
decisions, which in this case only contains the permit one, and returns the final decision for the policy, 
i.e. permit. Notice that the policy does not authorise requests not exposing the value assistant as a role 
and that the remaining requests are granted only if they ask for read operations. Also notice that if the 
policy’s target does not apply to arequest, then not-applicable is immediately returned without evaluating 
the enclosed rule and applying the combining algorithm. 

2.2 A glimpse of the FACPL Formal Semantics 

In this section, we briefly outline the formal semantics of FACPL (we refer the interested reader to l20l 
for a full account). The semantics is defined by following a denotational approach, which means that 

• we introduce some semantic functions mapping each FACPL syntactic construct to an appropriate 
denotation, that is an element of a semantic domain representing the meaning of the construct; 

• the semantic functions are defined in a compositional way, so that the semantic of each construct 
is formulated as a function of the semantics of its immediate sub-constructs. 

To this purpose, for each FACPL syntactic category, we specify the semantic domain into which the 
syntactic constructs map and define the semantic function [[ ]] by giving its domain and codomain, and 
by using semantic clauses to specify, inductively on the syntactic constructs, how the function acts on 
each construct. Thus, if P stands for a FACPL policy, [Pjr corresponds to the decision resulting from the 
application of the semantic function to (the syntactic object) P and (the semantic object) r representing 
an access request. 

A FACPL request, in order to be evaluated, is represented in its functional form. This is a function 
r belonging to the set R = Name {Value U U {-L}) containing all those total functions mapping 
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Table 2: The two-dimensional matrix for the permit-overrides combining algorithm 



permit 

deny 

not-applicable 

indeterminate 

permit 

permit 

permit 

permit 

permit 

deny 

permit 

deny 

deny 

indeterminate 

not-applicable 

permit 

deny 

not-applicable 

indeterminate 

indeterminate 

permit 

indeterminate 

indeterminate 

indeterminate 


attribute names (i.e., the structured names in the syntactic domain to either values, or set of values, 

or the special value _L (modelling the fact that an attribute name is missing). 

The semantics of a policy is then a function that, given a request, returns an authorisation decision. 
Formally, it is a function of the form R —> Decision, where Decision corresponds to the semantic (and 
syntactic) domain of authorisation decisions. To define the semantics of policies we use two clauses, one 
deals with rules, the other one with policies. For a generic rule {e target \expr), its semantics is given 
by the following clause: 


\{e target :rrpr)]]r = < 


e 

not-applicable 

indeterminate 


if \expr\r = true 

if \expr\r = false V [[rrpr]]r = _L 

otherwise 


where \expr\r is the value returned by evaluating the target expression expr with respect to the request r. 
Thus, the rule’s decision is returned when the target evaluates to true, which means that the rule applies 
to the request. Otherwise, it could be the case that the rule does not apply to the request, i.e. when the 
target evaluates to false or to _L (which means that the target is an attribute name missing in the request), 
or that an error has occurred while evaluating the target. 

Since the clause for policies relies on the semantics of combining algorithms, we first introduce it. 
For each combining algorithm, we use a two-dimensional matrix that, given two decisions, calculates 
the resulting combined one; then, by means of an iterative application of this matrix, we can define fhe 
decision refurned by fhe algorifhm when given as inpuf a sequence of decisions (each resulfing from fhe 
evaluafion of a policy or a rule). For example. Table |2] reports fhe mafrix for permit-overrides. Nofably, 
when a mafrix fakes info accounf fhe order of policy decisions (see, e.g., fhe mafrix for first-applicable 
in 1201), the combination is not associative. 

Finally, for a generic policy {a target :expr policies :P^}, where stands for a non-empty se¬ 
quence of policies or rules, its semantic clause is 


[[{a target :expr policies :F’+}]]r =< 


not-applicable 


if [[expr]]r = true A ^a{P^)]]r = e 
if [[exprjr = false V [[expr]]r = _L 

V ([[exprjr = true A [[a(F’+)]]r = not-applicable) 


indeterminate otherwise 

\ 


where [[a(F’+)]]r is the decision returned by evaluating the combining algorithm a on the sequence of 
(decisions resulting from the evaluation of) policies or rules Thus, the policy applies to the request 
when the target evaluates to true and the semantic of the combining algorithm a (which is applied to the 
enclosed sequence of policies and the request) returns a decision e, i.e. permit or deny. In this case, the 
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resulting decision of the policy is e. Instead, if the target evaluates to false or to _L, or the combining 
algorithm states that the contained sequence of policies is not applicable, the policy does not apply to the 
request. In the remaining cases, an error has occurred and the decision is indeterminate. 


3 Security Properties for Polices 

Policy-based specifications are sufficiently flexible and expressive to permit addressing, even in a mixed- 
up way, different security aspects. As stated in the Introduction, verifying whether a policy enforces a 
given security property is not straightforward. Therefore, in this section, we first present the attribute- 
based controls that the policy-based specifications must contain for ensuring various security properties. 
Then, we exploit the semantics of policies to formalise under which conditions a policy properly enforces 
such properties. 

We start by providing a more precise definition of the three general security principles mentioned in 
the Introduction. Given a controlled system, we let res € Res, Sub' C Sub and Act' C Act, where Res, 
Sub and Aci are respectively the set of resources, subjects and actions involved in the system’s operation. 
Then, the three principles can be defined as follows: 

• confidentiality, the resource res has the property of confidentiality with respect to subjects Sub' 
and actions Act' if none of the subjects in Sub' can execute actions in Act' on res\ 

• integrity: the resource res has the property of integrity with respect to subjects Sub' and actions 
Act' if actions in Act' executed by subjects in Sub' cannot alter the trustworthiness of res', 

• availability: the resource res has the property of availability with respect to subjects Sub' and 
actions Act' if all subjects in Sub' can execute all actions in Act' on res. 

It is worth noticing that the above principles could be naively instantiated by resorting to checks on 
the identity of subjects. For example, when a subject whose identifier is s tries to access the resource res, 
confidentiality could be achieved by denying the access to 5 if 5 E Sub'. However, this requires to know 
the identity of the requestor, as well as of all the other forbidden subjects, in advance. To overcome this 
limitation, different instantiations of these principles have been proposed, which rely on the features of 
subjects and resources for characterising the set Sub' of (dis)allowed subjects. We present some of these 
instantiations below, by focussing on the attribute-based controls necessary for expressing the wanted 
features and checking specific security aspects. 

Notably, from the access control point of view, the availability principle implies that the policy-based 
specifications have to grant the access to a subject that exhibits all the required credentials. This goal is 
achieved “by construction” in the proposed instantiations of the confidentiality and integrity principles, 
hence we do not further insist on the availability principle. 

3.1 Attribute-based Characterisation 

We use attribute names of the form subject/*, actions/* and resource/* to identify the characteristics 
of a subject willing to perform a given action on a resource. For example, for a given access tentative, 
action/id returns the identifier of the requested action, like e.g. read or write. 

In the following attribute-based characterisation of the security properties, we rely on the commonly 
used close-world assumption llT/l of access control systems, which forbids all behaviours that are not 
explicitly granted. We show in Section |5] how this assumption can be enforced using FACPL policies. 
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Confidentiality: multi-level security. The security policies commonly referred to as multi-level secu¬ 
rity 131 |25l represent typical instantiations of the confidentiality principle and are also the formal basis 
of the MAC approach. The goal of these kinds of policies is to prevent that a resource with a certain 
confidentiality level be disclosed to a subject with a lower level. To this aim, each subject and resource 
is assigned, through a function fi, a confidentiality level from a given partially ordered set < L, <l> of 
levels. In our case study, this function could be thus used to define, from the resources’ point of view, 
the confidentiality of loan requests and, from the subjects’ point of view, the trustworthiness of clerks. 

The Bell-LaPadula model Q formalises these security policies in terms of some security properties 
that must hold with respect to read and write action^ These properties are defined as follows: 

• no read-up: a subject s can read a resource res only if the the security level of the subject dominates 
the one of the object, i.e. ftires) <l fris)', 

• no write-down: a subject s can write a resource res only if the level of the subject s is dominated 
by the level of the object, i.e. fiis) <l /^{res). 

If we let the attributes subject/level and resource/1 eve I denote the confidentiality level assigned by 
function fi to subjects and resources, respectively, then the previous properties can be characterised in 
terms of policy-based specifications by the following rules: 

(permit target : equal(action/id,refl;rf) and leq(resource/level,subject/level)) 

(permit target : equal(action/id,>vnYr) and leq(subject/level, resource/level)) 

where function leq corresponds to the partial order relation <l. 

The Bell-LaPadula model is usually extended to also consider DAC controls. For instance, if we use 
access control lists as a DAC approach, these controls could be rendered by the following rule: 

(permit target: equal(action/id,rear/) and in(subject/id, resource/read.ids)) (2) 

where we assume that the attribute resource/read.ids returns the set of all subjects allowed to execute 
the read action on the resource. 

Integrity: separation of duty. The integrity principle regards various system aspects in addition to 
accesses authorisation, like e.g. the trustworthiness of conveyance and storage means used by the system 
to keep resources. Since we only focus on access control, we instantiate the principle in terms of the 
Biba model (3) and the property of separation of duty. 

The Biba model formalises integrity with respect to execution of read and write actions in terms of 
integrity levels associated with subjects and resources. Assuming that the integrity levels are defined in 
fhe same way as the confidentiality ones, the Biba model is the ‘dual’ of the Bell-LaPadula one in that it 
relies on the no read-down and no write-up properties, which can be characterised as before. 

An additional property that instantiates the integrity principle is separation of duty (SoD), which 
was introduced in the Clark-Wilson model f8] and since then has been largely adopted to define secure 
systems. In general, this property ensures that if two or more actions are required to perform a critical 
transaction, then these actions must be performed by at least two different subjects. SoD is valuable in 
deterring fraudulent behaviours, since no single subject has the possibility to perform complex actions, 
but only well-defined, elementary actions. 

*For the sake of presentation, we introduce the Bell-LaPadula model with respect to read and write actions; the same 
approach can be pursued for modelling the submit and approve actions of the case study. 
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A basic example of SoD is to prevent that an action be executed when a subject is assigned two roles 
that are conflicting, i.e. there is no separation of duties among the actions that these roles permit. For 
instance, if we assume roles rolel and role! to be in conflict, we can define a rule that permits a write 
action only when a subject exposes the first role but not the second one; the rule is as follows 

(permit target: equal(action/id,wnYc) and 

in(ro/cl,subject/role) and not(in(ro/c2,subject/role))) 

Indeed, the rule checks that the roles assigned to the subject, that are obtained through the attribute 
subject/role, include rolel, which is required for executing the read action, and not rolel. In the case 
study, by using the rule above where write, rolel and rolel are replaced by, respectively, approve, assis¬ 
tant and officier, we can ensure that a clerk assigned with both roles cannot perform an approve action. 

This last property is an example of static SoD, i.e. an integrity requirement that can be fulfilled by 
evaluating a single access request. However, if we define SoD in terms of conflicting actions, rather than 
in terms of conflicting roles as done before, checking a single access request is not adequate anymore 
to enforce the intended property. Indeed, SoD could be easily circumvented by executing conflicting 
actions in two or more attempts, as it is the case of a subject that is assigned, in two different instants 
of time, different roles granting conflicting actions. To avoid that the subject be authorised to execute 
both actions, we must resort to considering the previous actions it has performed, which is an example 
of dynamic SoD. This kind of properties can be still addressed by using policy-based specifications, but 
we need to use attributes for storing the history of the accesses previously performed by a subject. We 
will provide further details on this aspect when discussing future work. 

Role-based design: hybrid properties and least-privilege. The role-based design is a high level ap¬ 
proach that permits to enforce confidentiality and integrity properties on the controlled resources at the 
same time. It consists in assigning different roles to subjects within the system and using policies stating 
what accesses are allowed to subjects depending on the roles they have. Although it is not an instantia¬ 
tion of one of the three general security principles, we consider this approach explicitly since it is largely 
used due to its better scalability with respect to other models, like e.g. the Bell-LaPadula and Biba ones. 

The basic characterisation of role-based controls in terms of policy-based specifications is straight¬ 
forward: the attribute subject/role permits to define controls on the subject’s roles and Rule (l3]l is a 
concrete example of this. However, the role-based approach takes also different, more complicated 
forms |[2^ . that exploit role hierarchies, i.e. a role inherits the privileges of the roles that are higher up 
in the hierarchy, or constraints on role assignments, i.e. two conflicting roles cannot be assigned at the 
same time. The former case can be rendered by exploiting the hierarchy of polices or an appropriate 
ordering function, while the latter one by using an approach similar to that used for SoD properties. 
The characterisation of role-based controls thus formalises a sort of ‘hybrid’ property, consisting of both 
confidentiality and integrity aspects. 

Let us consider an hybrid property stating that an action write can be executed by all the subjects 
with assigned role rolel, or by any other subject in the underlying role hierarchy which is not assigned 
role roleA at the same time. Its characterisation in terms of attribute-based specifications can be defined 
as follows: 


(permit target : equal(action/id,>vntc) and 

sub-role(subject/role,ro/c3) and not(in(ro/c4,subject/role))) 

where we use the ad-hoc function sub-role to check if the subject’s role is a sub-role of (or coincides 
with) rolel and the additional control on role roleA to encode the integrity check. 
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A guideline commonly used in role-based design is least privilege. It means that each subject should 
not expose more privileges than those necessary to perform the requested action. Differently from the 
properties we have previously considered, least privilege is not implemented through specific rules. 
Rather, it affects the design choices pursued for defining access confrol policies. We will presenf more 
defails in fhe semanfic-based formalisation presenfed in fhe nexf section. 

3.2 Semantic-Based Formalisation 

A policy-based specificalion, as e.g. a FACPL policy, in addition fo fhe rules previously presenfed, con- 
fains many ofher elemenfs, such as e.g. ofher rules implementing additional confrols and confticf resolu¬ 
tion sfrafegies. We now formalise under which condifions a policy enforces a given security property. 

The formal represenfafion of a security properly is obfained by exploifing fhe facl lhal an access 
confrol requesl is an assignmenl of values fo a colleclion of allribules. We can Ihen use sels of requesls lo 
represenl fhe (non)secure sysfem behaviours wilh respecl fo a given properly. Formally, given a securify 
properly pr, we lef Rpr (resp., RpO be fhe permit (resp. deny) sel, i.e. fhe sel of requesls fhal represenl fhe 
secure (resp., nonsecure) behaviours wilh respecl lo pr, and Subpr (resp., Respr) be Ihe subsel of subjecls 
(resp., resources) for which Ihe property pr is defined. A policy P conlaining Ihe rules characterising pr 
correclly enforces such property if fhe following conditions hold 

Vr € Rpr ■ r {resource/id) £ ReSpr, r {subject/id) ^ Subpr ^ [[P]]r = permit 
Vr & Rpr ■ r{resource / id) £ Res pr ,r {subject/id) £ Subpr =A [[P]]r = deny 

where nolalion r(attr_name) indicates Ihe value assigned lo Ihe attribute named attr_name by Ihe requesl 
r. Hence, we require lhal all Ihe secure behaviours are allowed (i.e., all Ihe requesls in Rpr evaluate lo 
permit) and all the nonsecure ones are forbidden (i.e., all the requests in Rpr evaluate to deny). Notably, 
we consider the (non)secure behaviours that only refer to the subset of subjects and resources that the 
property pr takes into account. This means that the set Rpr is not the complementary set of Rpr with 
respect to the universe of all the possible behaviours of the system; rather it represents those behaviours 
that are considered nonsecure by the property pr. In the sequel we report the definition of the (non)secure 
sets of requests for each property we presented before. 

Confidentiality: multi-level security. The secure behaviours identified by the no read-up property 
corresponds to the set of requests Rnru whose elements r must satisfy the following conditions 

r(action/id) = rear/, r(resource/level) = Zi, r(subject/level) = Z2 : h,h^L, h<Lh 

The set Rnru instead contains those requests satisfying the following conditions 

r(action/id) = read , r(resource/level) = l[ , r(subject/level) = Z 2 : Zj,/^ G P , l[ I'l 

The permit and deny sets for the no write-down property are similarly defined. In case of DAC properties 
as e.g. that defined by Rule ([21), the requests of the set Rdac are characterised by the following conditions 

r(action/id) = rear/, r(resource/read.ids) = , r(subject/id) =5 : s € Sub res 

where Subres is set of all subjects allowed to execute the read action on the resource res. Instead, the 
elements of the deny set Rdac must satisfy the following conditions 

r(action/id) = read, r(resource/read.ids) = Sub/^^, r(subject/id) =5 : s ^ Sub/^^ 
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Indeed, the set of granted subjects Sub'^-g^ does not contain the subject s. 

Integrity: separation of duty. The no read-down and the no write-up properties, representing the Biba 
model, are formalised like the confidentiality ones. 

Let us consider the SoD property for a write action expressed by Rule (l3]l. Thus, if Rol is the set of 
authorised non conflicting sets of roles, i.e. all the sets contain rolel and not rolel, the secure behaviours 
Rsod are defined as follows 

r(action/id) = write , r(subject/role) =rol : rol ^ Rol 

The non secure behaviours are instead defined as follows 

r(action/id) = write , r(subject/role) = rof : rol' G Rolau\Rol 

where the set Rolau represents the set of all sets of roles that a subject can play in the system. Thus, a 
request is non secure when the set of subject’s roles does not contain rolel, i.e. the subject has not the 
right to execute the write action, or it contains rolel and rolel at the same time, i.e. the exposed roles 
are in conflict. 

Role-based design: hybrid properties and least-privilege. The secure and nonsecure behaviours iden¬ 
tified by hybrid properties are just a combination of the previous examples. The formalisation of the least 
privilege requires instead additional comments. 

Let us consider a security property pr and the set of request Rpr representing the secure behaviours 
with respect to such property. The sets of secure and nonsecure behaviours for the least privilege, with 
respect to pr, are defined as follows 

Rip = Rpr Rip = Rall\Rpr 

where Rail indicates all the possible requests. Therefore, in order to enforce the least privilege, a policy 
has to authorise all those behaviours of the system deemed as secure by the property pr and to forbid all 
the other behaviours, not only those violating pr as in the previous cases. All the behaviours that are not 
defined secure by pr are considered as nonsecure. Hence, forbidding them ensures that possibly granted 
accesses cannot be used to circumvent, in a malicious way, other policies in the system. 

4 Structural Properties for Policies 

We now address some of the properties proposed in the literature which refer to the structure of policies. 
We start considering completeness of a single policy, after which we will consider redundancy, disjoint¬ 
ness and coverage of one policy with respect to other ones. The properties dealing with multiple policies 
capture the relationships among the different sets of system behaviours they enforce. In this section, 
we report a uniform characterisation of these properties by means of the semantic-based approach used 
before. 

By referring to FACPL, we use P to range over policies, alg to range over combining algorithms and 
d to range over authorisation decisions. Moreover, we use Ran to denote the set of all possible requests. 

Completeness. A policy P is complete if there is no access request for which there is an absence of 
decision. Formally, this property can be rendered through the following condition 


Vr ^Raii - [Pjr / not-applicable 
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In fact, we require that the policy applies to any request, i.e. it always returns a decision different from 
not-applicable. Notably, in this formulation indeterminate is considered as an admissible decision; a 
more restrictive formulation could be defined that only accepts decisions permit and deny. 

Redundancy. Redundancy among policies means that to enforce the same set of system behaviours some 
policies are not needed. Therefore, if we eliminate redundant policies, we can improve performance 
of policy evaluation while leaving unchanged the enforced behaviours. Although the concept seems 
natural and quite simple, different formalisations, that often lack of precision, have been proposed in the 
literature. We follow an approach similar to |[T4l . 

Formally, if we let the FACPL policy S be defined as 5 = alg(Pi ) • ■ • )Pi)PiPi +\) ■ • ■ )Pn)> fhen fhe policy 
P is redundant wifh respecf fo S if fhe following condition holds 

'ire Rail - [[alg(Pi,...,P,-,P,P;+i,...,P„)]]r = [[alg(Pi,... ,P/,/’'+i,... ,P„)]]r 

In fad, we require fhaf, for any requesf, fhe decision relumed by S is nol affecfed by fhe presence of P. 
Nofably, fhis properly generalises in fhe obvious way fo fhe case S confains rules inslead of policies (fhus 
P would be a redundanl rule) and fo fhe case a fargel is presenf in S. 

Disjointness. Disjoinlness among policies means lhal such policies apply fo disjoinl sels of behaviours. 
Thus, fwo policies are disjoint if fhere is no requesf for which bolh policies evaluate fo permit or deny. 
Formally, policies P and P' are disjoint if fhe following condition holds 

V r € Rail ■ { [[P]]f 1^']]'^} 2 {permit, deny} 

It is worth noticing that disjoint polices can be combined with the assurance that the allowed or forbidden 
behaviours enforced by each of them are not in conflict, which simplifies the choice of the combining 
algorithm to be used. 

Coverage. Coverage among policies means that one of such policies enforce the same decisions as the 
other ones for a set of requests of interest. Formally, if P^ov is a set of requests, we say that the policy 
P covers the policy P' if, for each request r € Rcov to which P' applies, i.e. [[P']]r € (permit,deny}, P 
applies too and returns the same decision. Formally, it is expressed by the following condition 

'ire Rcov ■ [[p']]r G (permit, deny} ^ = [[^1]'' 

Thus, relatively to the set of requests of interest, P enforces at least the same allowed and forbidden 
behaviours as P'. Consequently, if P' also covers P, then the two policies enforce exactly the same 
behaviours relatively to the set of requests of interest. 

These structural properties permit to statically reason on the relationships among policies and provide 
useful support to system’s designers in developing and maintaining policy-based specifications. One 
technique they support is the change-impact analysis lITTIl . This analysis examines the effect of policy 
modifications for discovering unintended consequences of such changes. To be practically effective it 
requires that the verification of the previous properties be supported by automatic tools. We further deal 
with this issue in the next section. 

5 Verification of Properties 

The formalisation of security and structural properties presented in Sections [3] and |4] determines the 
conditions on attributes stating when a policy enjoys a certain property. To verify such conditions, we 
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need to take into account the various elements composing a policy. Specifically, the hierarchical structure 
of policies and the various elements originating the decisions make this verification cumbersome and 
error-prone if not supported by an automatised technique. As an example of the difficulties to be faced, 
we consider (part of) the policies modelling the case study, which address the no read-up and DAC 
security properties for read actions requested by a set of subjects Sub' on the resource loanDoc. Thus, 
we define various combinafion approaches for creating a policy confaining Rules ([Til and (O, and we 
sfudy for each approach if fhe fwo properties are properly enforced. 

The firsf combinafion we propose for fhe fwo rules is defined as follows 

{permit-overrides 

target: equal(resource/id,/ormDoc) and in(subject/id,5'Mfr') 
policies : 

(permit target : equal(action/id,rrar/) and leq(resource/level,subJect/level)) 

(permit target : equal(action/id,rrar/) and in(subject/id, resource/read.ids))} 

The chosen combination algorithm is permit-overrides, which seems the natural choice since each al¬ 
lowed behaviour is explicitly authorised. Notably, the policy’s target ensures that the policy exclusively 
applies to the considered resource loanDoc and to the subset of system’s subjects Sub'. 

To verify that this policy enforces the intended properties, we show that all the secure behaviours 
are authorised, while the nonsecure ones are forbidden. We consider first the no read-up property. As 
formalised in Section 13.21 the secure behaviours correspond to all the requests containing the resource 
and subject levels that respect the partial ordering relation. These ones clearly match the target of the first 
rule, hence this rule, as well as the permit-overrides algorithm, return permit. The nonsecure behaviours 
are instead represented by all the requests containing resource’s and subject’s levels not properly ordered. 
In this case, both internal rules do not apply and the permit-overrides algorithm returns not-applicable, 
because neither permit nor deny are returned by the rules. However, the nonsecure behaviours should 
be evaluated as deny, hence we can conclude that the policy does not properly enforce the no read-up 
property. The same also holds for the DAC property. 

To fix this first policy, we can replace the permit-overrides algorithm by the deny-unless-permit 
one, which ensures that deny is taken as the default decision whenever no rule evaluates to permit. In 
this case all the nonsecure behaviours of both properties are properly forbidden. However, as we are 
addressing two properties, the secure behaviours are all those ones that are secure, at the same time, for 
both properties. This means that permit must be returned only when the two rules apply at the same time 
as well, but this does not happen in the presented policies. In fact, the combining algorithm does not 
enforce any form of consensus between the two rules. As a matter of fact, a subject can circumvent the 
access control system reading a resource, e.g., only having the correct confidentiality level and not the 
discretionary access. 

This additional issue can be addressed by adding a new policy layer and requesting a strong consensus 
between the rules. The extended policy is thus as follows 

(deny-unless-permit 
policies : 

(strong-consensus 

target : equal(resource/id,ZoauDoc) and in(subject/id,5'MZj') 
policies : 

(permit target : equal(action/id,refl:rZ) and leq(resource/level,subject/level)) 

(permit target : equal(action/id,refl:<i) and in(subject/id, resource/read.ids)) }} 
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deny-unless-permit is used at top level to ensure that the resulting decisions of the overall policy will be 
only permit or deny. In the inner policy, strong-consensus ensures that permit is returned only when 
both internal rules apply at the same time. In this case, all secure and nonsecure behaviours of the two 
intended properties are properly enforced. Notably, we can achieve the same result by merging the two 
rules and avoiding the additional policy layer; however, the modelling approach we present permits to 
achieve separation of concerns among rules, which are thus easier to maintain and possibly change. 

Verifying that a policy properly enforces a set of properties is not straightforward. This example, 
which seems easy enough for being manually checked, shows us that also in case of simple policies 
we need an automated verification approach. Specifically, fhis approach musf be capable fo lake info 
accounl all Ihe aspecls of a policy specificalion, e.g. policy slralificafion and combining algorilhms, and 
lo exhauslively check all Ihe significanl requesls represenfing Ihe possible behaviours. A viable approach 
lowards an aulomafed verificafion of securily and slruclural properties is ouflined in Ihe nexl subseclion. 


5.1 Towards an Automated Verification Approach 

Aufomafising Ihe verificafion of properties permifs fo facililale Ihe analysis of policy-based specifica- 
lions. To enable such analysis, we need a formalism lhal, on Ihe one hand, permifs lo collapse hierarchi¬ 
cal policies info a single-layered represenlalion and lo uniformly represenl all policy elemenls and, on 
Ihe olher hand, is sufficienfly flexible fo deal wilh multiple domain values for alfribufe assignmenls. To 
Ibis aim, we propose a consfrainl-based formalism. 

Consfrainfs permif fo specify salisfacfion problems based bofh on boolean formulae and on formulae 
dealing wilh differenl Iheories as, e.g. linear arilhmelics. Such kind of formulae are called satisfiability 
modulo theories (SMT) formulae. Choosing an SMT-based approach is advocaled also by Ihe relevanl 
progress made in Ihe developmenl of aulomalic SMT solvers (e.g., Z3 EH), which make SMT formulae 
lo be exlensively employed in diverse analysis applications ESI- In addition, Ihe analysis of logic-based 
access conlrol policies reporled in [Tj poinls ouf lhal Ihe SMT-based approach is more effective lhan 
many olher ones, like e.g. Ihe approaches based on decision diagrams ifTTI or on description logic ifTTl . 
Of course, Ihe feasibilily of Ihe SMT-based approach crucially depends on decidabilily of fhe salisfi- 
abilify checks; in olher words, Ihe used conslrains musf be represenfed by decidable Iheories, as e.g. 
uninlerpreled funclions and array Iheories. 

To achieve a single-layered represenlalion of policies, we have fo provide a Iranslalion function from 
Ihe language used for wriling policies lo Ihe consfrainl-based formalism lhal preserves Ihe semantics of 
Ihe original language. Indeed, since FACPL is equipped wilh a formal semantics, il has lo be exploited 
for defining a rigorous encoding. Nolably, as Ihe evalualion of a policy can relum four possible decisions, 
we have lo define a differenl conslrainl for each of Ihem. 

A conslrainl-based represenlalion of policy-based specifications enables Ihe verifications of bolh 
securily and slruclural properties. Specifically, in Ihe case of securily properties, Ihe allribule values 
identifying Ihe class of (non)secure requesls correspond lo assignmenl assertions in Ihe conslrainl of 
inleresl (i.e. Ihe one modelling Ihe decision lo which Ihe requesls should evaluate) and Ihen, by means of 
an SMT-solver, il is checked if such conslrainl is salisfiable. If Ihis happens, il means lhal Ihe requesls of 
Ihe class can evaluate, under Ihe assignmenl model relumed by Ihe solver, lo Ihe decision modelled by Ihe 
conslrainl. In case of slruclural properties, we can instead define boolean combinations among Ihe single 
conslrainls of each policy, and Ihen check Ihe salisfiabilily of Ihe resulting conslrainl lo undersland if a 
cerlain properly holds. For inslance, Ihe disjoinlness belween Iwo policies holds if Ihe conslrainl resulting 
from Ihe implication of Ihe permit (resp., deny) conslrainls of bolh policies is nol salisfiable. 
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6 Related Works 

Policy-based specifications have recently been the subject of extensive research, both by industry and 
academia, in many application areas. In fact, policy languages have been adopted for managing different 
aspects of systems’ behaviour, not only access control but also adaptation enforcement and network 
management. A large variety of languages for defining access controls has been proposed, and the 
more significant ones follow two main specification approaches: rule-based, as e.g. XACML and 
Ponder f9|, and logic-based, as e.g. ASL ifTSl and the logical framework presented in |T|. We present 
the relevant features of these languages, showing the effectiveness of choosing FACPL as the target 
language for studying policies’ properties. Notably, the uniform approach based on attributes presented 
in ifT^ does not provide any evaluable property characterisation, but only an high-level access control 
model. 

XACML is the most widely-used instantiation of the ABAC approach. It relies on an XML-based 
syntax and permits to write policies and access requests. However, XML does not permit compact spec¬ 
ifications and, due to the lack of a formal semantics, an explicit unambiguous formalisation of request’s 
evaluation. The use of FACPL permits thus to avoid verbose examples, and to rely on a rigours formal 
semantics to formalise properties. 

Ponder is instead a strongly-typed language defined in terms of Event-Condition-Action rules. Dif¬ 
ferently from XACML and FACPL, it does not provide any explicit combination strategy to resolve 
conflicts. Thus, the presence of conflicts or inconsistency is statically analysed by means of abductive 
reasoning techniques |J3. This reasoning generates a refinement for the considered policy. Ponder, on 
the one hand, permits to avoid policy hierarchies, but, on the other hand, it does not provide any mod¬ 
ularity and compositionality in the specification of policies. The FACPL-based specification approach 
consists instead in basic building rules, that can be appropriately combined to enforce different security 
properties, ensuring separation of concerns in the enforced behaviours. 

The increasing spread of policy-based specifications has prompted the development of multiple veri¬ 
fication techniques like, e.g., property checking and behavioural characterisations. Such techniques have 
been implemented by means of different formalisms, varying from multi-terminal binary decision dia¬ 
grams (MTBDD) to different kinds of logics. We review the more relevant techniques and formalisms. 

The change-impact analysis of XACML policies presented in ifTll permits to study the consequences 
of policy’s modifications. In particular, to verify structural properties among policies by means of auto¬ 
matic tools, this approach relies on a MTBDD-based representation of policies. However, it cannot deal 
with many of the classical combining algorithms, e.g. all the XACML’s ones, and, as outlined in [TJ, an 
SMT-based approach (i.e. the one we are exploring), scales significantly better than the MTBDD one. 

The ASL language ITSl is a logical framework for the formalisation of access control policies. 
Specifically, it enables hierarchisation, conflict resolution, and role- and group-based definitions of access 
rights. Furthermore, by means of additional predicates representing a posteriori checks on authorisation 
decisions, it permits to easily express various history-dependent properties, e.g. dynamic separation of 
duty. Similarly, the framework in [Tj permits a logic-based specification of control policies. A policy is 
thus a list of constraint assertions that are evaluated by a SMT-based tool, and various structural prop¬ 
erties can be encoded in terms of additional, low-level assertions. The FACPL-based approach permits 
instead to abstract from the underlying logical means (that are still used to in the FACPL formal seman¬ 
tics and for the automatised analysis we foster), allowing a better usability for system’s designers of the 
properties formalisation. 

An additional logic-based analysis is the one presented in ifTTl . which aims at verifying structural 
properties of XACML policies. Specifically, it defines a partial encoding of XACML into description 
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logics and a set of supporting analysis services. However, this approach does not take into account many 
combining algorithms and, also, the decisions not-applicable and indeterminate, which are instead useful 
in the definition of structural properties. Furthermore, the used reasoning tool suffers the same scalability 
issues as the one based on MTBDD. 

Finally, the redundancy property has been object of specific infensive sfudies. In fad, fhe idenfifi- 
cafion of redundanf policies and fheir ‘safe’ eliminafion increases fhe evaluafion performance of access 
confrol sysfems. A rigorous formalisation of redundancy is proposed in ifTdIl . where an algorifhmic ap¬ 
proach for minimising access confrol policies is proposed and ifs compufafional complexify sfudied. 

7 Conclusion 

Policy-based specificafions are widely used fo regulafe fhe behaviour of sysfem’s entities relafively fo 
fhe access fo shared resources. The policy-based access confrol, by resorting fo fhe concepf of affribufe, 
is sufficienfly expressive fo represenf in an uniform way all classical access confrol approaches, varying 
from access confrol lisf and role-based fo discrefionary and mandafory ones. Policies permif indeed fo de¬ 
fine fine-grained, flexible and confexf-aware access confrols, fostering sysfems infegrafion, as attributes 
can be refrieved from differenf informafion sysfems. To ensure confidenfialify and infegrify principles, 
such policies need fo fake info accounf multiple securify aspecfs, e.g., fhe ones sfudied by well-known 
securify models, such as fhe Bell-LaPadula and Biba ones. However, enforcing in terms of policy-based 
specificafions fhe securify properties characferising such models is a fricky fask. In fad, fhe hierarchi¬ 
cal sfrucfure of policies, fhe presence of conflicl resolution sfrafegies and fhe infricacies deriving from 
fhe many confrols involved do nof permif fo easily check whefher a given securify properfy is properly 
enforced. By means of fhe FACPL policy language, we have provided some specification examples of 
a significanl sef of securify properfies, and showed under which condifions such properties are prop¬ 
erly enforced. To characterise fhe relationships wifh fhe behaviours fhaf differenf polices enforce, we 
have also formalised, in a uniform way, various properfies on fhe sfrucfure of policies. Furfhermore, 
fo effectively supporf system’s designers in developing and mainfaining policy-based specificafions, we 
ouflined a consfrainf-based approach enabling aufomafed verificafion of security and sfrucfural properfies 
by means of consfrainf solver fools. 

We conclude by reviewing some addifional properfies we plan fo sfudy in fhe nexf fulure. On fhe 
one hand, fo lake info accounf dynamic behaviours of sysfems, we wanf fo address hislory-dependenf 
securify properfies, and provide specialised formal analysis fechniques. On fhe ofher hand, access confrol 
policies can also be used fo produce, fogefher wifh fhe aufhorisafion decision, addifional acfions, named 
obligations, fhaf can adapf fhe compufing system’s configuration. To reason on obligations, we wanf fo 
formalise properties on confiicfs and dependencies among fhem. Furfher defails follow. 

History-Dependent Properties. Classical examples of history-dependent properties are dynamic SoD 
and Chinese Wall Q. Dynamic SoD properties correspond to enforcing separation of duty by evalu¬ 
ating not only the current subject’s request, but also the history of actions the subject has previously 
performed. Chinese Wall properties correspond instead to an hybrid instantiation of the confidentiality 
and integrity principles, where history is used to adapt the access rights granted by the confidentiality 
controls. Specifically, it means that a subject is only allowed to access resources which are not in conflict 
with any other resource that the subject has already accessed. 

Enforcing these properties within policy-based specifications means checking the history of system’s 
authorisations. This could be done, e.g., by means of attributes representing the history. These attributes 
should in fact collect all the information needed for property enforcing a considered history-dependent 
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property, e.g., in case of Chinese Wall, which resources have been already accessed. In order to formally 
verify that such properties are enforced, we need to enhance our semantic-based formalisation with an 
explicit representation of history. Possible approaches to pursue for achieving this formalisation are those 
used in Usage Control |[T^ . i.e. a novel access control model for ensuring continuous authorisation when 
an access is in progress. 

Obligations. Obligations have been introduced in access control for modelling the need of fulfilling 
additional actions in order to gain access. For instance, XACML supports the definition of obligations 
and, to allow an access, it requires that all obligations possibly generated by the policy evaluation are 
correctly fulfilled. Obligations can be fhus used fo adapf fhe computing sysfem’s configurafion. However, 
these obligations may have conditional requirements on their execution, e.g. conflicts and dependencies, 
that have to be taken into account. For instance, an obligation can require to be executed only if another 
one has not been already executed. To formalise and analyse properties on obligations, we plan to start 
from the representation model of obligation’s features outlined in [4], and instantiate such model with 
respect to the FACPL policy language. 
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